NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9084

Text File | 1996-08-05 | 3.5 KB | 71 lines

Newsgroups: comp.lang.c
Path: cwi.nl!dik
From: [e-mail] (Dik T. Winter)
Subject: Re: Tradition or what?
Message-ID: <[e-mail]>
Sender: [e-mail] (The Daily Dross)
Nntp-Posting-Host: chrysant.cwi.nl
Organization: CWI, Amsterdam
References: <danpop.825961872@rscernix> <[e-mail]> <danpop.826211387@rscernix>
Date: Fri, 8 Mar 1996 00:40:30 GMT

In article <danpop.826211387@rscernix> [e-mail] (Dan Pop) writes:
...
 > >> >Here are the three worst Microsoft coding rules, in my opinion at least:
...
 > >> >Any number greater than 2 must be a named constant.
...
 > >> Actually, the second rule is quite good (except that '2' should be replaced
 > >> by '1' :-)  Magic constants embedded in the code are a huge nuisance
 > >> for maintenability.  If you have to change an explicit (aka magic) constant
 > >> in a piece of code, how can you be sure that you aren't going to break
 > >> anything?  By changing a macro definition, you _know_ that you won't
 > >> break anything, because all the dependencies of that macro will be
 > >> automatically taken care of by the compiler (and your "make" utility).

This actually depends on the use of the constant.  Changing a constant can
actually break code whether it is done in a manifest constant or in a
named constant.
 > >
 > >I agree that there are good uses for giving a literal a name, and using
 > >that name instead of repeated usage of the literal, but to make a
 > >mandate that even if the literal were referenced only once you must give
 > >it a name would seem too extreme.
 >
 > The point is that software is not usually cast in concrete.  What you
 > thought to be a one-time magic constant might be used later (in a
 > future release/version of the program) in another place and, if you
 > don't follow the rule, chances are that it will be used again

If I write in some numeric code (using floats):
    approx = (f(x - h) + f(x) * 2.0 + f(x + h)) / (2.0 * h);
I am darn sure that all other occurences of the constants 2.0
are only accidental and unrelated to these occurences.  Moreover, I do
know that if I change one or both of the constants the code might fail
in a horrible fashion.  Or do you think the following is more readable:
    approx = (f(x = h) + f(x) * TWO + f(x + h)) / (TWO * h);
or do you have other suggestions for silly names here? Moreover, in
Gaussian quadrature formulas it is in many cases better to just write-out
the constants than replace them by meaningless macronames like
COEFFICIENT_0 etc. (and yes, I have no idea about finding more meaningful
names).  Such formula's are cast in concrete; you can not just replace
one of the constants, you can only replace the complete formula.  And
numerical mathematics has an awful lot of similar constants (and PI is
not one of them; that is an obvious candidate for a macro).

Similar things do happen in integer code too.  Take binary search; you
happen to divide by two a lot.  Change that to a macro?  What sensible
name do you suggest; and what would be the result if you change the
constant?  Moreover, the suggestion that using macro's makes changes
easier and simpler to comprehend are *not* true.  They lead to the
cases where code starts with:
  #define THREE 4
and in many cases it is not possible (in my opinion) to pick up more
sensible names.

The rule as such is *not* good.  There are too many cases where the
rule obscures the actual algorithm used.
--
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/